validate analytics event properties before sending - #23821
Conversation
MixpanelEvent.properties is Record<string, any> and most event classes
forward caller input verbatim, so nothing stopped a malformed payload
reaching Mixpanel. A collections_installation_failed row arrived in
2.4.0 carrying only {"0":"4",...} — a bare id string spread into an
object — with none of its real properties.
Add zod contracts for the collection-install and mod-install families,
validated at the single send boundary in trackEvent. Unknown keys are
stripped rather than rejected; nothing read from download metadata is
required, since those ids come through optional chaining and parseInt
and are legitimately absent for bundled and direct downloads. Garbage
is caught by requiring at least one recognized property to survive.
Events without a contract are still sent unvalidated.
part of LAZ-862
erri120
left a comment
erri120
left a comment
There was a problem hiding this comment.
With this change we now have three different places where the define a event contract:
- Mixpanel Lexicon
- This new runtime schema
- The existing
MixpanelEventtype and classes implementing it for typechecking
The issue is that these are not linked in any way. Making a change to the Mixpanel Lexicon doesn't impact our event classes, changing the runtime schema doesn't give us typechecking issues during development and changing the event classes won't pass validation without changing the new schema as well.
Since the linked ticket LAZ-862 is about malformed data reaching Mixpanel, I suggest checking if Mixpanel has a "strict" mode that rejects data not fitting the Lexicon. While we can change things in Vortex, users would actually have to run the latest version to send "valid" data, old versions of Vortex would continue sending malformed data.
As for what we can do inside Vortex, if we want to make sure we're only sending valid data as part of a schema, both the runtime and typechecking schemas should be the same, ie using zod and exporting both the Zod schema as a JavaScript object and a TypeScript type so that we get validation on all stages.
|
Nope - governance/workarounds for this will have to happen on the mixpanel/server side. |
2 participants
MixpanelEvent.properties is Record<string, any> and most event classes forward caller input verbatim, so nothing stopped a malformed payload reaching Mixpanel. A collections_installation_failed row arrived in 2.4.0 carrying only {"0":"4",...} — a bare id string spread into an object — with none of its real properties.
Add zod contracts for the collection-install and mod-install families, validated at the single send boundary in trackEvent. Unknown keys are stripped rather than rejected; nothing read from download metadata is required, since those ids come through optional chaining and parseInt and are legitimately absent for bundled and direct downloads. Garbage is caught by requiring at least one recognized property to survive. Events without a contract are still sent unvalidated.
part of LAZ-862